前言

上一篇我們談到 Ingress 的優點與不足。Ingress 適合用來做簡單的外部入口管理，但當系統逐漸成長，需求從 「路由」 變成 「流量治理」 時，Ingress 就顯得力不從心。
這就是 Gateway API 誕生的背景。

Gateway API 的定位

Gateway API 不是全新的東西，而是 Ingress 的進化版，由 Kubernetes SIG-Network 社群設計，目標是：

• 提供 一致的 API 規範，不再依賴不同 Controller 的私有 annotation。
• 支援 更細粒度的流量治理（例如 HTTP header match、流量分流、跨 namespace 管理）。
• 將「流量入口」與「路由規則」分離，讓 基礎設施團隊 與 應用團隊 可以分工管理。

Gateway API 的核心資源

Gateway API 定義了一組新的 CRD：

1. GatewayClass

   • 定義由誰來提供 Gateway，例如 NGINX、Istio。
   • 類似 Ingress Controller 的抽象層。

2. Gateway

   • 代表實際的「入口」實體（如 LoadBalancer）。
   • 指定會開哪些 Port、TLS 設定。

3. HTTPRoute / TCPRoute / GRPCRoute

   • 定義具體的流量轉發規則。
   • 支援 Host、Path、Header、Method 等細粒度匹配。

4. ReferenceGrant

   • 允許跨 namespace 的路由規則。

與 Ingress 的比較

實務例子

假設一個 Gateway API 的設定：

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    protocol: HTTP
    port: 80
---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  parentRefs:
  - name: my-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: api-svc
      port: 80

這樣就能做到類似 Ingress 的功能，但可擴展性更強。

Gateway API 如何補足 Ingress 的不足

1. 統一規範

   • 不再依賴 Controller 特定的 annotation。

2. 細粒度路由

   • 除了 Path/Host，還能用 Header、Method、權重做流量分流。

3. 角色分工

   • 基礎設施團隊只需要管理 Gateway（入口），開發者只要管理 HTTPRoute。
   • 避免了 YAML 爆炸與權責不清的問題。

4. 跨 namespace 支援

   • ReferenceGrant 允許不同 namespace 的服務共享 Gateway。

5. 多協議支援

   • 讓 gRPC、TCP 服務也能透過統一方式暴露。

總結

• Ingress 適合中小型應用，快速暴露服務。
• Gateway API 適合大型微服務架構，需要進階流量治理與團隊分工時。

Gateway API 並不是要馬上取代 Ingress，而是逐步成為更通用、更標準化的選項。
如果你的團隊已經遇到 Ingress 規格不足的痛點，Gateway API 值得開始嘗試。